1. Field of the Invention
The present invention relates to the field of computer or digital systems. More specifically, the present invention relates to bus bridging on computer/digital systems.
2. Background Information
To support the high-bandwidth data transfers demanded by modern applications, data are clocked across the buses of today""s computer/digital systems at tremendous rates. To achieve, reliable, high speed data transfer, such system often includes a number of buses arranged in a hierarchy and interconnected by devices call bus bridges.
A bus bridge is basically a load isolating device that allows multiple devices to appear as a single capacitive load to a bus. Although the reduced capacitive loading increases the maximum frequency at which a bus can be operated, the bridge adds a layer of complexity to the design and operation of the computer/digital system. One reason is because requests to transfer data from a requester side of a bridge to a target side of the bridge must often be buffered in the bridge. This is often caused by the bridge having to arbitrate with other devices to gain control of the target-side bus. As arbitration time may vary, it is usually desirable to buffer the requested data transfer, and then cause the device which requested the data transfer to relinquish the requester-side bus. Thus, other transfers may take place on the requester-side bus, while the bus bridge is performing the requested data transfer. If a read operation has been requested, the returned data also must typically be buffered, while the bridge notifies the requester that the data is available (or while the bridge waits for the requester to ask if the data is available) and while the requester arbitrates to re-gain control of the requester-side bus.
It will be appreciated that the above-described buffering of requests and data imposes a latency penalty on any data transfer which must cross the bus bridge. Moreover, because the latency penalty is incurred with each transfer across the bridge, the smaller the quantum of data per bridged transfer, the lower the effective bandwidth of the data transfer.
One technique used to avoid loss of bandwidth due to bus bridging is to speculatively pre-fetch additional data in response to each data transfer request. Assuming that the speculatively pre-fetched data is actually used by the requesting device, pre-fetching effectively increases the quantum of data per bridged transfer and therefore increases the effective bandwidth of data transfer across the bridge. However, if the speculatively pre-fetched data are not used, the discarded pre-fetches waste the bandwidth on the target-side bus consumed for the pre-fetching.
One other problem that may also arise when data is pre-fetched, is that even though the requesting device may need the pre-fetched data, its internal data buffer may be too shallow to read all of the pre-fetched data in the bridge in a single read transaction. Consequently, after retrieving a portion of the pre-fetched data, the requesting device relinquishes control of the requester-side bus (also referred to as logically disconnecting from the bus bridge) while it performs the internal operation of transferring the data from its internal data buffer to its other internal resources. Because of the requesting device relinquishing control of the bus, prior art bridges typically assume that the requesting device has completed its transfer and reallocates the pre-fetch buffer for other data transfer operation. As a result, the pre-fetched data remaining in the pre-fetch buffer is lost, and the bandwidth consumed for the pre-fetch is wasted. Consequently, when the requesting device re-gains control of the requester-side bus and attempts to read data beginning where it left off, the read transaction must now cross the bridge and be handled by target-side devices again. Thus, in cases where the data buffer of the requesting device is substantially shallower than the pre-fetch buffer in the bridge, the bandwidth gains achieved by data pre-fetching can be significantly eroded.
Loss of pre-fetched data may be addressed by the support of split transactions. In a split transaction bus, each transfer request is typically accompanied by an identifier that identifies the requesting device. The identifier allows pre-fetched data to be matched with a requesting device even if the requesting device disconnects and then reconnects. Data is xe2x80x9cre-streamedxe2x80x9d upon reconnection by the requesting device. However, the identifier scheme significantly increases complexity to the design and operation of the system. An alternative solution is to provide a cache memory in the bridge. Experience has shown that too can be an expensive proposition.
In U.S. patent application Ser. No. 09/012,775, issued Jan. 2, 2001 as U.S. Pat. No. 6,170,030 entitled xe2x80x9cMethod and Apparatus for Restreaming Data That Has Been Queued In A Bus Bridge Devicexe2x80x9d, filed on Jan. 23, 1998, an improved method for addressing the problem through a set of queue management rules was disclosed. In U.S. patent application Ser. No. 09/266,744, entitled xe2x80x9cComputer System Having Improved Data Transfer Across A Bus Bridgexe2x80x9d, filed on Mar. 12, 1999, another method through xe2x80x9cdecomposedxe2x80x9d fetches was disclosed. Both applications have common assignee as the present application. Each approach has its pros and cons. The present invention provides another approach to address the problem, offering certain advantages otherwise not available in the other approaches.
A bus agent provides to a bus bridge a read data request targeting a data source bridged by the bus bridge. The read data request includes a read address indicating a starting storage location of the requested data, and a read size indicator indicating the size of the requested data. The bus bridge, in response, facilitates provision of the requested data to the bus agent. The facilitation includes streaming buffered ones of the requested data to the bus agent through one or more successive streaming connections to the bus bridge by the bus agent. The bus bridge factors into consideration, the included read size indicator, in managing re-streaming eligibility of remaining buffered ones of the requested data.